Hi, Continuing a discussion started over at [1]. Moving this to a new thread so that other thread can focus on Unix cleanup, and both threads can get CI coverage... 1. In a few places, it is alleged that both __CYGWIN__ and WIN32 might be defined at the same time. Do you think we should try to get rid of that possibility? I understand that we have to have a few tests for __CYGWIN__ here and there, because eg file permissions don't work quite right and there's not much we can do about that. But it seems a bit unhelpful if we also have to worry about a more-or-less POSIX-ish build taking WIN32 paths at uncertain times if we forget to defend against that, or wonder why some places are not consistent. A quick recap of the three flavours of Windows platform we have to handle, as I understand it: * MSVC: Windowsy toolchain, Windowsy C * custom perl scripts instead of configure * msbuild instead of make * MSVC compiler * Windows C APIs * we provide our own emulation of some POSIX C APIs on top * MSYS: Unixy toolchain, Windowsy C * configure (portname = "win32") * make * GCC compiler * Windows C APIs * we provide our own emulation of some POSIX C APIs on top * Cygwin: Unixy toolchain, Unixy C * configure (portname = "cygwin") * make * GCC compiler * POSIX C APIs (emulations provided by the Cygwin runtime libraries) (The configure/make part will be harmonised by the Meson project.) The macro WIN32 is visibly defined by something in/near msbuild in MSVC builds: /D WIN32 is right here in the build transcripts (whereas the compiler defines _WIN32; good compiler). I am not sure how exactly it is first defined in MSYS builds; I suspect that MSYS gcc might define it itself, but I don't have access to MSYS to check. As for Cygwin, the only translation unit where I could find both __CYGWIN__ and WIN32 defined is dirmod.c, and that results from including <windows.h> and ultimately <minwindef.h> (even though WIN32 isn't defined yet at that time). I couldn't understand why we do that, but I probably didn't read enough commit history. The purpose of dirmod.c on Cygwin today is only to wrap otherwise pure POSIX code in retry loops to handle those spurious EACCES errors due to NT sharing violations, so there is no need for that. Proposal: let's make it a programming rule that we don't allow definitions from Windows headers to leak into Cygwin translation units, preferably by never including them, or if we really must, let's grant specific exemptions in an isolated and well documented way. We don't seem to need any such exemptions currently. Places where we currently worry about the contradictory macros could become conditional #error directives instead. 2. To make it possible to test any of that, you either need a working Windows+Cygwin setup, or working CI. I'm a salty old Unix hacker so I opted for the latter, and I also hope this will eventually be useful to others. Unfortunately I haven't figured out how to get everything working yet, so some of the check-world tests are failing. Clues most welcome! The version I'm posting here is set to run always, so that cfbot will show it alongside others. But I would imagine that if we got a committable-quality version of this, it'd probably be opt-in, so you'd have to say "ci-os-only: cygwin", or "ci-os-only: cygwin, windows" etc in a commit to your private github account to ask for it (or maybe we'll come up with a way to tell cfbot we want the full works of CI checks; the same decision will come up for MSYS, OpenBSD and NetBSD CI support that my colleague is working on). There are other things to fix too, including abysmal performance; see commit message. 3. You can't really run PostgreSQL on Cygwin for real, because its implementation of signals does not have reliable signal masking, so unsubtle and probably also subtle breakage occurs. That was reported upstream by Noah years ago, but they aren't working on a fix. lorikeet shows random failures, and presumably any CI system will do the same... I even wondered about putting our own magic entry/exit macros into signal handlers, that would use atomics to implement a second level of signal masking (?!) but that's an uncommonly large bandaid for a defective platform... and trying to fix Cygwin itself is a rabbithole too far for me. 4. When building with Cygwin GCC 11.3 you get a bunch of warnings that don't show up on other platforms, seemingly indicating that it interprets -Wimplicit-fallthrough=3 differently. Huh? [1] https://www.postgresql.org/message-id/CA%2BhUKGKZ_FjkBnjGADk%2Bpa2g4oKDcG8%3DSE5V23sPTP0EELfyzQ%40mail.gmail.com